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        Problem Definition and Classification of BGP Route Leaks

Abstract

   A systemic vulnerability of the Border Gateway Protocol routing
   system, known as "route leaks", has received significant attention in
   recent years.  Frequent incidents that result in significant
   disruptions to Internet routing are labeled route leaks, but to date
   a common definition of the term has been lacking.  This document
   provides a working definition of route leaks while keeping in mind
   the real occurrences that have received significant attention.
   Further, this document attempts to enumerate (though not
   exhaustively) different types of route leaks based on observed events
   on the Internet.  The aim is to provide a taxonomy that covers
   several forms of route leaks that have been observed and are of
   concern to the Internet user community as well as the network
   operator community.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7908.
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1.  Introduction

   Frequent incidents [Huston2012] [Cowie2013] [Toonk2015-A]
   [Toonk2015-B] [Cowie2010] [Madory] [Zmijewski] [Paseka] [LRL] [Khare]
   that result in significant disruptions to Internet routing are
   commonly called "route leaks".  Examination of the details of some of
   these incidents reveals that they vary in their form and technical
   details.  In order to pursue solutions to "the route-leak problem" it
   is important to first provide a clear, technical definition of the
   problem and enumerate its most common forms.  Section 2 provides a
   working definition of route leaks, keeping in view many recent
   incidents that have received significant attention.  Section 3
   attempts to enumerate (though not exhaustively) different types of
   route leaks based on observed events on the Internet.  Further,
   Section 3 provides a taxonomy that covers several forms of route
   leaks that have been observed and are of concern to the Internet user
   community as well as the network operator community.  This document
   builds on and extends earlier work in the IETF [ROUTE-LEAK-DEF]
   [ROUTE-LEAK-REQ].

2.  Working Definition of Route Leaks

   A proposed working definition of "route leak" is as follows:

   A route leak is the propagation of routing announcement(s) beyond
   their intended scope.  That is, an announcement from an Autonomous
   System (AS) of a learned BGP route to another AS is in violation of
   the intended policies of the receiver, the sender, and/or one of the
   ASes along the preceding AS path.  The intended scope is usually
   defined by a set of local redistribution/filtering policies
   distributed among the ASes involved.  Often, these intended policies
   are defined in terms of the pair-wise peering business relationship
   between ASes (e.g., customer, transit provider, peer).  For
   literature related to AS relationships and routing policies, see
   [Gao], [Luckie], and [Gill].  For measurements of valley-free
   violations in Internet routing, see [Anwar], [Giotsas], and
   [Wijchers].

   The result of a route leak can be redirection of traffic through an
   unintended path that may enable eavesdropping or traffic analysis and
   may or may not result in an overload or black hole.  Route leaks can
   be accidental or malicious but most often arise from accidental
   misconfigurations.

   The above definition is not intended to be all encompassing.  Our aim
   here is to have a working definition that fits enough observed
   incidents so that the IETF community has a basis for developing
   solutions for route-leak detection and mitigation.
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3.  Classification of Route Leaks Based on Documented Events

   As illustrated in Figure 1, a common form of route leak occurs when a
   multihomed customer AS (such as AS3 in Figure 1) learns a prefix
   update from one transit provider (ISP1) and leaks the update to
   another transit provider (ISP2) in violation of intended routing
   policies, and further, the second transit provider does not detect
   the leak and propagates the leaked update to its customers, peers,
   and transit ISPs.

                                      /\              /\
                                       \ route leak(P)/
                                        \ propagated /
                                         \          /
              +------------+    peer    +------------+
        ______| ISP1 (AS1) |----------->|  ISP2 (AS2)|---------->
       /       ------------+  prefix(P) +------------+ route leak(P)
      | prefix |          \   update      /\        \  propagated
       \  (P)  /           \              /          \
        -------   prefix(P) \            /            \
                     update  \          /              \
                              \        /route leak(P)  \/
                              \/      /
                           +---------------+
                           | customer(AS3) |
                           +---------------+

                  Figure 1: Basic Notion of a Route Leak

   This document proposes the following taxonomy to cover several types
   of observed route leaks while acknowledging that the list is not
   meant to be exhaustive.  In what follows, the AS that announces a
   route that is in violation of the intended policies is referred to as
   the "offending AS".

3.1.  Type 1: Hairpin Turn with Full Prefix

   Description: A multihomed AS learns a route from one upstream ISP and
   simply propagates it to another upstream ISP (the turn essentially
   resembling a hairpin).  Neither the prefix nor the AS path in the
   update is altered.  This is similar to a straightforward path-
   poisoning attack [Kapela-Pilosov], but with full prefix.  It should
   be noted that leaks of this type are often accidental (i.e., not
   malicious).  The update basically makes a hairpin turn at the
   offending AS's multihomed AS.  The leak often succeeds (i.e., the
   leaked update is accepted and propagated) because the second ISP
   prefers customer announcement over peer announcement of the same
   prefix.  Data packets would reach the legitimate destination, albeit
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   via the offending AS, unless they are dropped at the offending AS due
   to its inability to handle resulting large volumes of traffic.

   o  Example incidents: Examples of Type 1 route-leak incidents are (1)
      the Dodo-Telstra incident in March 2012 [Huston2012], (2) the
      VolumeDrive-Atrato incident in September 2014 [Madory], and (3)
      the massive Telekom Malaysia route leak of about 179,000 prefixes,
      which in turn Level3 accepted and propagated [Toonk2015-B].

3.2.  Type 2: Lateral ISP-ISP-ISP Leak

   Description: The term "lateral" here is synonymous with "non-transit"
   or "peer-to-peer".  This type of route leak typically occurs when,
   for example, three sequential ISP peers (e.g., ISP-A, ISP-B, and
   ISP-C) are involved, and ISP-B receives a route from ISP-A and in
   turn leaks it to ISP-C.  The typical routing policy between laterally
   (i.e., non-transit) peering ISPs is that they should only propagate
   to each other their respective customer prefixes.

   o  Example incidents: In [Mauch-nanog] and [Mauch], route leaks of
      this type are reported by monitoring updates in the global BGP
      system and finding three or more very large ISPs' Autonomous
      System Numbers (ASNs) in a sequence in a BGP update's AS path.
      [Mauch] observes that its detection algorithm detects for these
      anomalies and potentially route leaks because very large ISPs do
      not, in general, buy transit services from each other.  However,
      it also notes that there are exceptions when one very large ISP
      does indeed buy transit from another very large ISP, and
      accordingly, exceptions are made in its detection algorithm for
      known cases.

3.3.  Type 3: Leak of Transit-Provider Prefixes to Peer

   Description: This type of route leak occurs when an offending AS
   leaks routes learned from its transit provider to a lateral (i.e.,
   non-transit) peer.

   o  Example incidents: The incidents reported in [Mauch] include
      Type 3 leaks.

3.4.  Type 4: Leak of Peer Prefixes to Transit Provider

   Description: This type of route leak occurs when an offending AS
   leaks routes learned from a lateral (i.e., non-transit) peer to its
   (the AS's) own transit provider.  These leaked routes typically
   originate from the customer cone of the lateral peer.
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   o  Example incidents: Examples of Type 4 route-leak incidents are (1)
      the Axcelx-Hibernia route leak of Amazon Web Services (AWS)
      prefixes causing disruption of AWS and a variety of services that
      run on AWS [Kephart], (2) the Hathway-Airtel route leak of 336
      Google prefixes causing widespread interruption of Google services
      in Europe and Asia [Toonk2015-A], (3) the Moratel-PCCW route leak
      of Google prefixes causing Google's services to go offline
      [Paseka], and (4) some of the example incidents cited for Type 1
      route leaks above are also inclusive of Type 4 route leaks.  For
      instance, in the Dodo-Telstra incident [Huston2012], the leaked
      routes from Dodo to Telstra included routes that Dodo learned from
      its transit providers as well as lateral peers.

3.5.  Type 5: Prefix Re-origination with Data Path to Legitimate Origin

   Description: A multihomed AS learns a route from one upstream ISP and
   announces the prefix to another upstream ISP as if it is being
   originated by it (i.e., strips the received AS path and re-originates
   the prefix).  This can be called re-origination or mis-origination.
   However, somehow a reverse path to the legitimate origination AS may
   be present and data packets reach the legitimate destination albeit
   via the offending AS.  (Note: The presence of a reverse path here is
   not attributable to the use of a path-poisoning trick by the
   offending AS.)  But sometimes the reverse path may not be present,
   and data packets destined for the leaked prefix may be simply
   discarded at the offending AS.

   o  Example incidents: Examples of Type 5 route leak include (1) the
      China Telecom incident in April 2010 [Hiran] [Cowie2010]
      [Labovitz], (2) the Belarusian GlobalOneBel route-leak incidents
      in February-March 2013 and May 2013 [Cowie2013], (3) the Icelandic
      Opin Kerfi-Simmin route-leak incidents in July-August 2013
      [Cowie2013], and (4) the Indosat route-leak incident in April 2014
      [Zmijewski].  The reverse paths (i.e., data paths from the
      offending AS to the legitimate destinations) were present in
      incidents #1, #2, and #3 cited above, but not in incident #4.  In
      incident #4, the misrouted data packets were dropped at Indosat's
      AS.

3.6.  Type 6: Accidental Leak of Internal Prefixes and More-Specific
      Prefixes

   Description: An offending AS simply leaks its internal prefixes to
   one or more of its transit-provider ASes and/or ISP peers.  The
   leaked internal prefixes are often more-specific prefixes subsumed by
   an already announced, less-specific prefix.  The more-specific
   prefixes were not intended to be routed in External BGP (eBGP).
   Further, the AS receiving those leaks fails to filter them.
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   Typically, these leaked announcements are due to some transient
   failures within the AS; they are short-lived and typically withdrawn
   quickly following the announcements.  However, these more-specific
   prefixes may momentarily cause the routes to be preferred over other
   aggregate (i.e., less specific) route announcements, thus redirecting
   traffic from its normal best path.

   o  Example incidents: Leaks of internal routes occur frequently
      (e.g., multiple times in a week), and the number of prefixes
      leaked range from hundreds to thousands per incident.  One highly
      conspicuous and widely disruptive leak of internal routes happened
      in August 2014 when AS701 and AS705 leaked about 22,000 more-
      specific prefixes of already-announced aggregates [Huston2014]
      [Toonk2014].

4.  Additional Comments about the Classification

   It is worth noting that Types 1 through 4 are similar in that a route
   is leaked in violation of policy in each case, but what varies is the
   context of the leaked-route source AS and destination AS roles.

   A Type 5 route leak (i.e., prefix mis-origination with data path to
   legitimate origin) can also happen in conjunction with the AS
   relationship contexts in Types 2, 3, and 4.  While these
   possibilities are acknowledged, simply enumerating more types to
   consider all such special cases does not add value as far as solution
   development for route leaks is concerned.  Hence, the special cases
   mentioned here are not included in enumerating route-leak types.

5.  Security Considerations

   No security considerations apply since this is a problem definition
   document.
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